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Abstract 


This  report  explores  the  translation  of  MetaH  into  ACME  as  a  first  step  into  the  translation  of 
MetaH  to  other  architecture  description  languages  (e.g.,  Rapide)  to  take  advantage  of  any 
toolsets  developed  for  the  target  language.  We  start  by  comparing  the  meta-models  of  ACME 
and  MetaH,  we  establish  mapping  rules  for  each  MetaH  construct,  and  we  present  a  full 
MetaH  example  taken  from  the  MetaH  Library  at  Honeywell.  The  report  concludes  with  a 
brief  description  of  possible  alternative  paths  to  obtain  (limited)  Rapide  behavioral  specifica¬ 
tions  from  MetaH  timing  and  sequencing  of  operations. 
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1  Introduction  to  MetaH  and  ACME 


The  ACME  interchange  format  was  originally  conceived  as  a  way  to  share  tool  capabilities 
provided  by  a  particular  ADL  with  other  ADLs,  while  avoiding  the  production  of  many  pair¬ 
wise  language  translators.  ACME  has  been  embraced  the  DARPA  EDCS  Program  as  a 
“domain-neutral”  architecture  description  language  for  building  a  core  set  of  architectural 
tools  and  as  a  common  core  representation  for  more  domain-specific  ADLs. 

The  basic  aim  of  translating  architectural  design  descriptions  in  an  ADL  to  and  from  the 
ACME  interchange  format  is  to  provide  access  to  emerging  tool  capabilities  without  having  to 
produce  a  redundant  architectural  specification  in  their  native  ADLs.  In  general,  such  transla¬ 
tors  present  two  basic  difficulties: 

•  meta-model  differences  between  an  ADL  and  ACME 

•  attribute  labeling  and  semantic  differences  between  ADLs 

ACME’S  meta-model  includes  a  first-class  connector  concept,  whereas  not  all  ADLs  support 
such  a  concept.  ADLs  that  do  not  support  first-class  connectors  do,  by  necessity,  support  alter¬ 
native  interconnection  or  configuration  concepts.  The  challenge  of  producing  translators  for 
these  ADLs  is  to  determine  what  kinds  of  simple  or  complex  connectors  can  be  used  in  ACME 
for  whatever  the  ADL  provides  to  describe  component  inter-relationships,  while  preserving 
their  structural  and  coordination  semantics.  For  the  ADLs  that  have  been  used  as  exemplars  in 
the  development  of  ACME — UniCon  and  Rapide,  for  example — ^reasonable  solutions  to  this 
problem  have  been  found. 

Attributes  present  more  significant  challenges  to  constructing  translators.  Non-structural 
design  information,  which  is  typically  the  subject  of  modeling,  analysis,  and  generation  tools, 
is  expressed  in  ACME  by  attribute,  or  property  lists.  ACME  is  not  concerned  with  this  infor¬ 
mation  per  se,  but  merely  associates  it  with  elements  of  the  structural  description  and  commu¬ 
nicates  it  between  translations.  The  problems  arise  between  two  different  ADLs  using  ACME 
as  an  interchange  format.  The  two  may  use  the  same  attribute  label  for  different  information, 
different  attribute  labels  for  the  same  information,  or  may  provide  the  same  information  in  dif¬ 
ferent  ways.  They  may  also  provide  the  same  information  in  the  same  way,  but  have  subtle  (or 
not  so  subtle)  differences  in  interpretation  within  the  context  of  particular  tools.  As  a  facet  of 
the  ongoing  development  of  ACME,  although  not  directly  related  to  its  design,  it  has  been  pro¬ 
posed  that  a  core  set  of  attributes  with  consistent  semantics  across  ADLs  be  adopted.  In  the 
interim,  issues  of  agreement  must  be  considered  pairwise  between  ADLs,  and  in  the  longer 
term  such  issues  will  remain  for  attributes  outside  of  the  core  set. 
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The  MetaH  architectural  description  language  (ADL)  and  associated  toolset  support  architec¬ 
tural  modeling  of  embedded  real-time  system  applications.  Based  on  the  architectural  model 
the  toolset  performs  syntactic  consistency  checks  regarding  the  architectural  structure,  schedu- 
lability  analysis  of  the  real-time  tasks,  and  generates  executable  code  that  integrates  applica¬ 
tion  components  into  a  communicating  set  of  processes,  complemented  with  a  runtime  system 
that  contains  a  tailored  scheduler  and  communication  support. 

MetaH  focuses  on  system  integration  and  is  designed  to  interface  with  more 
specialized  toolsets  that  produce  functional  components  (in  the  paper,  “An 
aspect  of  MetaH  extensibility  is  the  ability  to  interface  with  other  ADLs  and 
associated  analysis  capabilities.  ”)  These  are  often  called  DSLs,  but  I  think  they 
often  have  the  flavor  of  specialized  ADLs.  For  example,  one  could  think  of  inte¬ 
grating  the  USC/ISl  message  handling  code  generator  with  MetaH,  so  that 
MetaH  could  be  used  to  integrate  message-handling  subsystems  generated  by 
those  tools  into  an  overall  embedded  system  [Vestal  98]. 


Honeywell  has  used  MetaH  as  an  architectural  language  in  a  number  of  application  settings 
and  has  extended  and  completed  the  modeling  capability  with  specialized  sub-languages  and 
tools.  An  aspect  of  MetaH  extensibility  is  the  ability  to  interface  with  other  ADLs  and  associ¬ 
ated  analysis  capabilities. 

This  report  explores  the  translation  of  MetaH  into  ACME  as  a  first  step  into  the  translation  of 
MetaH  to  other  ADLs  (e.g.,  Rapide)  to  take  advantage  of  any  toolsets  developed  for  the  target 
language.  We  start  by  comparing  the  meta-models  of  ACME  and  MetaH,  we  establish  map¬ 
ping  rules  for  each  MetaH  construct,  and  we  present  a  full  MetaH  example  taken  from  the 
MetaH  Library  at  Honeywell.  The  report  concludes  with  a  brief  description  of  possible  alter¬ 
native  paths  to  obtain  (limited)  Rapide  behavioral  specifications  from  MetaH  timing  and 
sequencing  of  operations. 

We  appreciate  the  comments  and  suggestions  on  earlier  drafts  of  this  report  offered  by  Peter 
Feiler  (CMU/SEI)  and  Steve  Vestal  (Honeywell).  Dave  Garland  (CMU/SCS)  and  his  team 
made  available  to  us  the  AcmeStudio  tools  used  to  test  the  translations. 
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2  Software  Architecture  Specification 


This  chapter  explains  the  syntax  and  semantics  of  the  MetaH  architecture  description  language 
and  their  translation  into  ACME.  We  have  tried  to  the  maximum  extent  to  retain  the  structure 
of  Chapter  5  in  the  MetaH  Programmer ’s  Manual  [MetaH  98]  to  check  the  completeness  of 
the  approach,  i.e.,  we  have  accounted  for  each  and  every  MetaH  feature. 

A  MetaH  software  architecture  specification  for  an  application  consists  of  a  series  of  interface 
and  implementation  specifications  (the  components),  together  with  a  single  application  speci¬ 
fication  that  describes  the  connections  between  components.  The  interface  and  implementa¬ 
tion  specifications  explain  how  types  of  objects  are  constructed  from  previously  specified 
types  of  objects.  The  application  specification  combines  a  software  object  with  a  hardware 
object  (the  execution  platform)  and  type  packages  (the  data  types  exchanged  between  compo¬ 
nents)  to  specify  a  complete  system  architecture. 

We  retain  this  flavor  in  the  translation  to  ACME.  MetaH  interface  specifications  are  translated 
to  ACME  component  types.  MetaH  implementation  specifications  are  translated  into  ACME 
component  types  extending  the  previous  type.  MetaH  objects  are  translated  into  ACME 
instances  of  the  appropriate  type  (i.e.,  the  type  derived  from  the  implementation  specification). 
Finally,  a  MetaH  application  is  also  translated  into  an  ACME  component  type.  After  the 
MetaH  description  is  translated,  a  single  ACME  system  is  declared  as  an  instance  of  the 
ACME  component  type  generated  from  the  MetaH  application. 

Whenever  we  discuss  ACME  and  MetaH  constructs  with  similar  names  (e.g.,  “Port”)  we  will 
prefix  the  name  of  the  construct  with  the  name  of  the  language  (e.g.,  “ACME  Port”)  to  make 
explicit  which  flavor  of  the  construct  we  are  talking  about. 


2.1  The  ACME  “MetaH_Family” 

To  facilitate  the  translation  to  ACME  we  use  the  ACME  Family  construct  to  decl£u-e  a  collec¬ 
tion  of  standard  MetaH-related  types,  types  used  in  any  MetaH  to  ACME  translation.  This 
family  (“MetaH_Family,”  Figure  2-1)  is  augmented  with  the  (translated)  MetaH  type  pack¬ 
ages,  interfaces,  implementations,  and  application. 
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Family  MetaH_Family  {)  = 

{/*  BEGIN  STANDARD  METAH  DECLARATIONS  */ 

property  type  MH_mode_subclass  = 
enum  {MH_initial,  MH_other}; 
property  type  MH_port_subclass  = 
enum  MH_out}; 

property  type  MH__process_subclass  = 
enum  {MH_periodic ,  MH_aperiodic } ; 
property  type  MH_event_subclass  = 

enum  {MH_interrupt ,  MH_signal,  MH__nudge,  MH_node} ; 
property  type  MH_execution_path  =  sequencer- 
property  type  MH_error_path  =  sequence 
property  type  MH_Implementation_name  =  string; 
property  type  MH__Interface_name  =  string; 

port  type  MH_^ort  =  { }  ; 
port  type  iyiH_event  =  { }  ; 

component  type  MH_mode  = 

{port  MH_event__port :  MH_port 

=  (property  MH_port_subclass  =  MH_in;};}; 
component  type  MH__macro  =  { }  ; 
component  type  MH_monitor  =  {}; 
component  type  MH_package  =  { } ; 
component  type  MH_subprogram  =  { } ; 
component  type  MH_process  = 

(port  MH_event_port :  MH_port 

=  (property  MH_port_subclass  =  MH_in;};}; 
component  type  MH_error_model  =  ( } ; 
component  type  MH_error__state  =  ( }  ; 

connector  type  MH_connector  = 

(roles  (MH_source;  MH_sink} ; 
property  MH__port_identif ier :  string;}; 

/*  The  MetaH  connector  roles  are  wired- in  */ 

/*  BEGIN  EXAMPLE  SPECIFIC  DECLARATIONS  */ 


};  /*  End  MetaH_Family  */ 

System  identifier:  MetaH_Family  = 

(component  identifier  =  new  identifier;}; 

Figure  2-1:  MH_Family 
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The  ACME  system  declared  at  the  end  of  the  translation  uses  the  declarations  in  MH_Family 
and  declares  an  instance  of  the  ACME  component  type  derived  from  the  MetaH  application. 
This  should  become  clear  through  the  examples  provided  in  the  report. 


2.2  Interface  and  Implementation  Classes 

MetaH  interface  and  implementation  specifications  can  be  divided  into  two  main  groups  based 
on  the  class  of  object  being  specified:  source  objects  (type  packages,  subprograms,  packages, 
and  monitors)  and  higher-level  objects  (processes,  macros,  modes,  and  applications)  ([MetaH 
98],  Section  5.1.3).  We  make  no  distinction  between  these  two  groups  and  how  they  are  trans¬ 
lated  into  ACME. 

With  three  exceptions,  all  MetaH  constructs  can  be  translated  one-to-one  into  ACME  con¬ 
structs.  That  is,  we  can  translate  interfaces,  implementations,  and  systems  into  ACME  types  as 
they  occur.  Although  there  is  no  requirement  that  the  translation  be  done  “on  the  fly”,  it  is 
reassuring  that  this  simple  rule  applies! 

The  first  two  exceptions  to  the  rule  are  MetaH  type  packages  interfaces  (Section  2.2.1)  and 
MetaH  interfaces  (Section  2.3)  with  internal  components.  In  both  cases  we  must  wait  until  we 
have  the  corresponding  implementation  before  translating  the  construct  into  ACME.  The  third 
exception  are  MetaH  equivalence  connections  (Section  2.4.3).  We  need  to  go  back  an  annotate 
sets  of  components  with  an  ACME  attribute  identifying  them  as  members  of  a  set. 


2.2.1  Type  Packages 

A  MetaH  type  package  consists  of  a  collection  of  type  declarations  for  input  and  output  buffer 
variables.  These  buffer  variables  are  the  ports.  ([MetaH  98],  Section  5. 1.3. 1.1) 

Type  packages*  are  one  case  in  which  a  MetaH  entity  does  not  map  directly  into  one  ACME 
entity.  We  have  to  break  the  type  package  so  that  each  individual  type  identifier  is  translated 
into  an  ACME  port  type  declaration  (i.e.,  a  MetaH  type  package  is  a  collection  of  data  type 
declarations,  each  of  which  is  translated  into  a  different  ACME  port  type.)  We  need  to  do  this 
bundling  and  breaking  because  each  data  type  must  be  annotated  with  its  own  individual 
MetaH  attributes.  To  achieve  the  same  effect  in  ACME  we  make  the  variables  first  class  citi¬ 
zens,  i.e.,  ACME  port  types  and  then  we  annotate  them  with  ACME  properties. 

For  example,  consider  the  following  MetaH  type  package  in  Figure  2-2  (a).  The  MetaH  type 
package  “PORT_TYPES”  declares  two  data  types  (“ANY_TYPE”  and  “ANOTHER_TYPE”) . 
Each  of  these  is  translated  into  a  separate  ACME  port  type,  declared  by  extending  the  basic 


1 .  Type  packages  were  known  as  “port  type  modules”  in  previous  version  of  the  MetaH  documentation  and  toolset. 
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type  MH_port_type  declared  in  MH_Family,  and  annotated  with  all  the  various  MetaH 
attributes  (actually,  it  is  more  than  just  attributes;  any  piece  of  information  available  about  the 
types  is  captured  as  an  ACME  property.  For  example,  we  have  no  use  for  “PORT_TYPES” 
itself  but  it  is  useful  to  remember  the  name  of  the  original  MetaH  enclosure,  thus 
PORT_TYPES  is  saved  as  a  property  of  both  ANY_TYPE  and  ANOTHER_TYPE).  The  result¬ 
ing  ACME  port  type  declarations  appear  in  Figure  2-2  (b) 


2.2.2  Subprograms 

MetaH  subprogram  interfaces  identify  the  events  that  might  be  raised  by  a  subprogram  (out 
events)  and  ports  that  a  subprogram  sends  or  receives  messages  through  ([MetaH  98],  Section 
5.1.3.1.2). 

MetaH  subprograms  are  translated  just  like  MetaH  processes  (Section  2.2.5)  except  that  the 
ACME  component  type  extends  a  predefined  ACME  type  “MH_subprogram.” 


2.2.3  Packages 

A  package  is  a  collection  of  executable  subprograms.  MetaH  package  interfaces  identify  the 
events  that  might  be  raised  by  subprograms  in  a  package;  ports  that  subprograms  in  a  package 
send  or  receive  messages  through;  and  subprograms  and  packages  that  are  visible  to  other 
objects.  ([MetaH  98],  Section  5. 1.3.1. 3). 

MetaH  packages  are  translated  just  like  MetaH  processes  (Section  2.2.5)  except  that  the 
ACME  component  type  extends  a  predefined  ACME  type  “MH_package.” 


2.2.4  Monitors 

A  monitor  is  a  special  type  of  package  object  that  is  shared  by  multiple  processes.  ([MetaH 
98],  Section  5.1.3.1.4). 

MetaH  monitors  are  treated  like  MetaH  processes  (Section  2.2.5)  except  that  the  ACME  com¬ 
ponent  type  extends  a  predefined  ACME  type  “MH_monitor.” 


2.2.5  Processes 

MetaH  process  interfaces  identify  events  that  might  be  raised  by  a  process,  ports  that  a  process 
sends  or  receives  messages  through,  and  subprograms,  packages,  and  monitors  that  can  be 
shared  with  other  processes  ([MetaH  98],  Section  5.1.3.2.1).. 


6 


CMU/SEI-98-SR-006 


type  package  PORT_TYPES  is 
ANOTHER_TYPE :  type; 

ANY_TYPE:  type; 
end  PORT_TYPES; 

type  package  implementation  PORT_TYPES . I80960MC  is 
attributes 

ANY_TYPE'SourceDataSize  :=  16  B; 

ANY_TYPE ' SourceFile  : =  "port_types . a" ; 
ANOTHER_TYPE’SourceDataSize  :=  32  B; 
ANOTHER_TYPE ’ SourceFile  : =  "port_types . a" ; 
end  PORT_TyPES .18096  OMC ; 


(a)  MetaH  Type  Package  Declaration 


port  type  any_type 

extends  MH_port_type 
with 

{property  MH_Interface_name  =  "port_types" ; 
property  MH__Implementation_Name  =  "I80960MC"; 
property  MH_SourceDataSize  =  16; 
property  MH_SourceFile  =  "port_types . a" ; } ; 


port  type  another_type 
extends  MH_port_type 
with 

{property  MH_Interf ace_name  =  "port__types"  ; 
property  MH_Implementation_Name  =  "I80960MC"; 
property  MH_SourceDataSize  =  32; 
property  MH_SourceFile  =  "port_types .a" ; } ; 


(b)  ACME  Port  Type  Declarations 

Figure  2-2:  MetaH  Type  Package  and  Translation  into  ACME 

MetaH  process  interfaces  are  translated  into  ACME  component  types  extending  a  predefined 
ACME  type  “MH_process.”  MetaH  process  implementations  are  translated  into  ACME  com¬ 
ponent  types  extending  the  ACME  type  derived  from  the  process  interface.  For  example,  the 
MetaH  process  interface  and  implementation  in  Figure  2-3  (a)  are  translated  into  the  ACME 
component  types  in  Figure  2-3  (b). 
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MH_process  includes  a  pseudo  input  port  “MH_port_event.”  This  “port”  is  used  to  establish 
event-to-port  connections. 

MetaH  event  and  ports  declarations  are  translated  into  instances  of  predefined  ACME  types 
“MH_event”  or  “MH_port.”  All  additional  information  (e.g.,  port  direction)  is  translated  into 
ACME  properties  as  illustrated  in  Figure  2-5. 

If  a  process  contains  internal  components,  the  implementation  structure  is  translated  into  an 
ACME  representation,  i.e.,  a  System  plus  (optional)  Bindings. 


2.2.6  Macros 

A  MetaH  macro  allows  multiple  processes  to  be  grouped  to  form  an  abstract  object  and  a 
macro  component  can  be  declared  anywhere  a  process  component  can  be  declared  ([MetaH 
98],  Section  5.1.3.2.2). 

MetaH  macros  are  treated  Just  like  MetaH  processes  (Section  2.2.5)  except  that  the  ACME 
component  type  extends  a  predefined  ACME  type  “MH_macro.” 

2.2.7  Modes 

MetaH  mode  interfaces  identify  events  that  might  be  raised  by  a  mode,  ports  that  a  mode  sends 
or  receives  messages  through,  and  subprograms,  packages,  and  monitors  that  can  be  shared 
with  other  modes,  macros,  and  processes.  An  application  can  only  be  executing  in  one  mode  of 
operation  at  a  time  ([MetaH  98],  Section  5.1.3.2.3). 

MetaH  modes  are  treated  just  like  MetaH  Macros  (Section  2.2.6)  except  that  the  ACME  com¬ 
ponent  type  extends  a  predefined  ACME  type  “MH_mode.” 

MetaH  modes  differ  from  MetaH  macros  in  that  only  one  mode  can  be  active  at  a  time.  There 
is  no  counterpart  to  MetaH’s  modes  in  ACME,  i.e.,  there  are  no  dynamic  configuration  fea¬ 
tures.  We  choose  instead  to  treat  Modes  the  same  way  we  treat  Macros  (i.e.,  groups  of  Pro¬ 
cesses),  with  an  added  property  “MH_Mode_Class_Name.”  The  semantics  of  this  property  is 
that  if  multiple  “macros”  share  the  same  class  name,  only  one  may  be  executing  at  a  time. 
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process  Pi  is 

pl_input :  in  port  PORT_TYPES . ANY_TYPE; 
update:  out  port  PORT_TYPES . ANOTHER_TYPE; 
feedback:  in  port  PORT_TYPES .ANOTHER_TYPE; 
end  Pi; 

process  implementation  PI. EXAMPLE  is 
attributes 

self 'Period  :=  25  ms; 

self ’ SourceFile  :=  "pl_ports . a" ,  "pl.a"; 

self ' SourceTime  :=  2  ms; 
end  PI. EXAMPLE; 


(a)  MetaH  Process  Declaration 


component  type  pi 

extends  MH_process 
with 

{port  pl_input:  MH_port  = 

{property  MH_port_type  =  "any_type"; 
property  MH__port_subclass  =  MH_in;  }  ; 
port  update:  MH__port  = 

{property  MH_port_type  =  "another_type" ; 
property  MH  port  subclass  =  MH_out;}; 
port  feedback:  MH_port  = 

{property  MH__port_type  =  ''another_type"  ; 
property  MH  port  subclass  =  MH_in; } ; 

}; 


component  type  pl_example 
extends  pi 
with 

{property  MH_Period  =  25; 

property  MH_SourceFiles  =  { "pl_ports . a" ,  "pl.a"}; 

property  MH_SourceTime  =  2 ; } ; 


(b)  ACME  Process  Declaration 


Figure  2-3:  MetaH  Process  and  Translation  into  ACME 
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In  MetaH,  if  processes,  macros,  and  modes  are  components  in  the  same  mode,  then  each  pro¬ 
cess  and  macro  is  included  in  every  sibling  mode  component.  The  MetaH  processes  and  mac¬ 
ros  are  translated  into  ACME  component  types,  as  usual,  but  instances  of  these  types  get 
replicated  in  every  sibling  mode.  This  simplifies  things  because  then  sibling  modes  would  be 
self-contained.  This  is  in  the  spirit  of  MetaH,  where 

Modes  and  macros/processes  together  form  a  kind  of  hierarchical  state  machine 
sublanguage.  There  are  submodes  and  (eventually)  a  kind  of  parallel  mode 
composition,  the  toolset  flattens  such  hierarchical  specifications  into  a  final 
mode  transition  diagram  [Vestal  98]. 


2.2.8  Applications 

The  highest  level  of  MetaH  specification  is  an  application  ([MetaH  98],  Section  5.1.3.2.4). 

A  MetaH  application  is  translated  into  an  ACME  component  type  (a  mode,  macro,  or  process) 
plus  an  ACME  system.  The  ACME  system  consists  of  a  single  component  declaration,  an 
instance  of  the  component  type  obtained  from  the  MetaH  application. 


2.2.9  Error  Models 

An  error  model  declares  a  set  of  fault  events,  a  set  of  error  states,  and  a  set  of  paths  that  define 
transitions  between  error  states  in  response  to  fault  events.  Each  path  declared  in  an  error 
model  is  a  finite  state  machine,  where  the  states  are  error  states  and  the  transitions  occur  in 
response  to  fault  events.  An  attribute  that  can  be  defined  for  every  source  and  hardware  object 
is  the  error  model  path  used  to  model  the  response  of  that  object  to  fault  events  ([MetaH  98], 
Section  5.1. 3.2.5]). 

MetaH  error  model  interfaces  are  translated  into  ACME  component  types  extending  a  pre¬ 
defined  ACME  type  “MH_error_model.”  MetaH  error  model  implementations  are  translated 
into  ACME  component  types  extending  the  ACME  type  derived  from  the  error  model  inter¬ 
face. 

Error  model  events  and  states  are  translated  into  instances  of  predefined  ACME  types 
“MH_event”  and  “MH_error_state,”  respectively. 

Error  paths  are  translated  into  ACME  properties  (a  sequence  of  state  transitions)  as  described 
in  Section  2.4.4.2. 
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2.3  Component  Declarations 

Each  interface  and  implementation  specification  can  contain  zero  or  more  component  declara¬ 
tions  ([MetaH  98],  Section  5.1.4). 

Consider  the  MetaH  example  in  Figure  2-4  (a).  This  example  presents  a  problem  if  we  handle 
the  interface  and  the  implementation  as  the  usual  separate  component  type  declarations  and 
extensions.  Not  only  can  we  not  “extend”  an  ACME  representation,  but  in  addition,  in  MetaH 
every  object  in  an  interface  is  also  considered  to  be  a  component  of  the  implementation.  Thus 
we  must  wait  until  we  have  the  MetaH  implementation  to  complete  the  translation  and  gener¬ 
ate  the  ACME  representation.  Note  that  we  must  tag  the  various  pieces  so  we  know  where  they 
came  from  in  case  we  want  to  translate  back  to  MetaH,  as  shown  in  Figure  2-4  (b). 


2.3.1  Component  Classes,  Types,  and  Subclasses 

Event,  port,  and  type  objects  may  appear  as  components  of  an  interface  ([MetaH  98],  Section 
5.1.4.1). 

Types  are  treated  as  instances  of  ACME  type  MH_port_type,  as  shown  in  Figure  2-2.  MetaH 
event  and  port  declarations  are  translated  into  instances  of  predefined  ACME  types 
“MH_event”  or  “MH_port”  respectively.  All  additional  information  (e.g.,  port  direction)  is 
translated  into  ACME  properties  as  illustrated  in  Figure  2-5. 


2.3.1 .1  Port  Type  and  Subclass  Declaration 

A  port  must  be  classified  as  either  an  in  or  out  port.  Ports  are  typed  and  directional,  and  con¬ 
nections  can  only  be  specified  between  ports  whose  types  and  directions  are  compatible 
([MetaH  98],  Section  5.1.4.1.1). 

The  port  directions  are  captured  as  ACME  property  “MH_port_subclass”  with  values 
{“MH_in,”  “MH_out”}  defined  in  MetaH_Family. 

2.3.1 .2  Event  Subclass  Declaration 

MetaH  event  components  (other  than  those  specified  in  error  models)  must  be  subclassified  as 
either  in  or  out  events.  MetaH  event  components  (other  than  those  specified  in  error  models) 
may  optionally  be  subclassified  as  either  nudge,  signal,  interrupt,  or  mode  events  ([MetaH  98], 
Section  5. 1.4. 1.2). 
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process  FOO  is 

RESULT:  out  port  PTYPES.INT; 

Q:  monitor  QUEUE . BOUNDED ; 
end  FOO; 

process  implementation  FOO. BAR  is 
COMP:  subprogram  CONTROLLER. PID; 
end  FOO. BAR; 


(a)  MetaH  Interface  and  Implementation  with  Components 


component  type  FOO 
extends  MH  process 
with 

{port  RESULT:  MH_port  = 

{property  MH_port_type  =  "PTYPES.INT"; 
property  MH_port_subclass  =  MH_out;}; 

>; 

component  type  FOO_BAR  extends  FOO  with 
{representation 

{system  MH_some_name  = 
component  Q  = 

new  QUEUE_BOUNDED 
extended  with 

(property  MH_origin  =  MH_interface; } ; 
component  COMP  = 

new  CONTROLLER_PID 
extended  with 

(property  MH_origin  =  MH_implementation; } ; 

}; 

}; 

>; 

(b)  ACME  Translation 


Figure  2-4:  MetaH  Interface  and  Implementation  with  Components  and  Translation 
into  ACME 
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m_out :  out  port  PORT_TYPES . ANY_TYPE ; 


(a)  MetaH  Port  Declaration 


port  m_out :  MH_port  = 

{property  MH_port_type  =  "any_type"; 
property  MH_port_subclass  =  MH_out;}; 


(b)  ACME  Port  Declaration 


Figure  2-5:  MetaH  Port  Declaration  and  Translation  into  ACME 

The  event  subclass  is  captured  as  the  value  of  ACME  property  “MH_event_subclass”  with 
values  {“MH_nudge,”  “MH_signal “MH_interrupt,”  “MH_mode”}  defined  in 
MetaH_Family.  The  event  direction  is  captured  as  the  value  of  ACME  property 
“MH_port_subclass”  with  values  {“MH_in,”  “MH_out”}  defined  in  MetaH_Family. 


2.3.1 .3  Process  Subclass  Declaration 

Processes  are  classified  as  either  periodic  or  aperiodic.  A  periodic  process  is  dispatched  at  a 
fixed  frequency  specified  using  the  Period  attribute.  An  aperiodic  process  is  dispatched  by  an 
event  arrival,  where  the  events  that  can  dispatch  an  aperiodic  process  are  those  connected  to 
that  process  ([MetaH  98],  Section  5.1.4.1.3). 

The  process  subclass  is  captured  as  the  value  of  ACME  property  “MH_process_subclass”  with 
values  {“MH_periodic,”  “MH_aperiodic”}  defined  in  MetaH_Fainily. 

The  subclassification  can  appear  in  either  the  process  implementation  or  in  the  individual 
component.  That  is,  the  property  could  be  bound  in  either  place  but  it  must  be  bound  eventu¬ 
ally.  Event  connections  to  aperiodic  processes  are  described  in  Section  2.4.2. 
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2.3.1 .4  Mode  Subclass  Declaration 


In  any  specification  that  has  mode  components,  exactly  one  of  the  modes  must  be  classified  as 
the  initial  mode,  even  if  there  is  only  one  mode  component.  Event  connections  can  be  used  to 
change  modes  at  runtime  ([MetaH  98],  Section  5. 1.4. 1.4). 

The  mode  subclass  is  captured  as  the  value  of  ACME  property  “MH_mode_subclass”  with 
values  {“MH_initial,”  “MH_other”}  defined  in  MetaH_Family.  Event  connections  to  mode 
are  described  in  Section  2.4.2 


2.3.1 .5  State  Subclass  Declaration 

Exactly  one  state  in  an  error  model  must  classified  as  the  initial  state,  even  if  there  is  only  one 
state  declared  in  the  error  model  ([MetaH  98],  Section  5.1.4.1.5). 

The  state  subclass  is  captured  as  the  value  of  ACME  property  “MH_state_subclass”  with  val¬ 
ues  {“MHJnitial,”  “MH_other”}  defined  in  MetaH_Family. 


2.3.2  Component  Visibility  and  Naming 

See  the  MetaH  Programmer's  Manual,  Section  5.1.5  [MetaH  98]. 

We  assume  that  we  are  translating  a  correct  MetaH  description  and  that  all  syntactic  and 
semantic  checks  have  been  performed. 


2.4  Connection  Declarations 

Connections  in  MetaH  serve  two  purposes.  They  are  used  to  declare  connections  between  the 
interface  elements  of  the  various  components  in  an  implementation;  they  are  also  used  to 
equivalence  (sharing  of)  objects.  For  instance,  a  monitor  of  one  process  may  be  equivalenced 
to  a  monitor  of  another,  indicating  that  the  two  processes  share  the  same  monitor  ([MetaH  98], 
Section  5.1.6). 

Connectors  are  not  first  class  citizens  in  MetaH.  In  ACME  we  make  them  explicit  by  declaring 
them  explicitly  as  instances  of  connector  type  “MH_connector.”  Port  and  event  connections 
are  mapped  to  ACME  attachments  or  bindings  depending  on  which  components  are  being 
connected.  In  any  event,  the  “citizenship  status”  of  MetaH  connectors  seems  to  be  mostly  a 
syntactic  issue: 
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Internally,  the  MetaH  tools  create  a  connection  object.  MetaH  connections  are 
not  first-class  objects  as  with  other  ADLs  in  that  the  user  cannot  declare  con¬ 
nector  implementations  with  all  the  power  available  for  declaring,  say,  process 
implementations.  However,  connections  are  objects  in  the  sense  that  they  can 
have  attributes  defined.  We  expect  to  add  support  for  a  limited  form  of  user- 
declared  connector  implementation  by  allowing  a  connector  to  have  an  associ¬ 
ated  software  component,  e.g.  a  subprogram  to  do  representation  or  type  con¬ 
version.  The  proposed  syntax  starts  to  get  close  to  first-class  connector  objects, 
e.g.  con_name:  port  A. In_P  <-  user_defined  (B.Out_P,  C.Out_P);  The  exact 
implementation  for  “user_defined”  is  to  be  inferred  from  the  types  of  the  ports, 
vaguely  like  overload  resolution.  This  does  not  exist  yet,  it  is  merely  a 
preliminary  proposed  extension,  but  might  possibly  be  of  interest  to  think  about 
[Vestal  98], 


2.4.1  Port  Connections 

Ports  may  only  be  connected  to  other  ports  ([MetaH  98],  Section  5. 1.6.1). 

For  every  MetaH  port  connection  between  components  of  an  implementation  we  declare  an 
ACME  connector  (an  instance  of  component  “MH_port_connector,”  with  preassigned  roles 
“MH_source”  and  “MH_sink”)  and  an  ACME  attachment  section  connecting  the  ports  to  the 
roles  of  the  connector,  as  illustrated  in  Figure  2-6. 

For  every  MetaH  port  connection  between  a  component  of  an  implementation  and  a  port  of  the 
corresponding  interface  we  declare  an  ACME  binding  between  the  two  ports.  ^ 

A  MetaH  port  connection  can  have  an  optional  identifier.  If  so,  it  is  saved  as  an  ACME  prop¬ 
erty  “MH_identifier”  of  the  ACME  connector. 


2.4.2  Event  Connections 

An  event  may  be  connected  to  an  aperiodic  process,  to  a  mode,  or  to  another  event  ([MetaH 
98],  Section  5. 1.6.2). 


1 .  Since  ACME  attachments  are  declared  inside  a  system  and  ACME  bindings  are  declared  at  the  same  level  as  the  system 
within  a  representation,  attachments  and  bindings  can  not  be  mixed.  Any  binding  declarations  must  be  postponed  until  we 
are  done  with  the  attachments  and  the  system  declaration,  and  we  are  back  at  the  representation  level. 


CMU/SEI-98-SR-006 


15 


<<C»  P2  .  feedback  <-  PI. update; 


(a)  MetaH  Port  Connection 


Connector  MH_connector_l  = 
new  MH_port_connector 

extended  with  {property  MH_identif ier  =  "C"}; 
Attachments 

{p2. feedback  to  MH_connector_l .MH_sink; 
pi. update  to  MH_connector_l .MH_source; } ; 


(b)  ACME  Connector  and  Attachment  Declarations 

Figure  2-6:  MetaH  Port  Connection  and  Translation  into  ACME 

2.4.2.1  Event  to  Event  Connections 

Event  connections  within  an  object  implementation  vector  events  to  out  events  and  from  in 
events  declared  in  that  object’s  interface.  Event  connections  have  no  attributes  and  an  event 
connection  label  serves  only  for  documentation  ([MetaH  98],  Section  5.1.6.2.1). 

Event-to-event  connections  are  treated  the  same  way  as  port-to-port  connections  (Section 
2.4.1).  For  every  MetaH  event-to-event  connection  between  components  of  an  implementation 
we  declare  an  ACME  connector  (an  instance  of  component  type  “MH_event_connector”)  and 
an  ACME  attachment  section  connecting  the  ports  to  the  roles  of  the  connector.  For  every 
MetaH  event-to-event  connection  between  a  component  of  an  implementation  and  an  event  of 
the  corresponding  interface  we  declare  an  ACME  binding  between  the  two  ports. 

2.4.2.2  Event  to  Process  Connections 

An  aperiodic  process  may  be  connected  to  an  event.  When  the  event  occurs  the  process  will  be 
dispatched  ([MetaH  98],  Section  5.1. 6.2.2). 

Every  process  comes  with  a  pre-declared  port,  “MH_event_port”  (declared  in  “MH_port”). 
This  allows  event-to-process  connections  to  be  handled  just  as  port-to-port  (or  event-to-event) 
connections  (Section  2.4.1). 
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Multiple  events  may  ultimately  dispatch  the  same  aperiodic  process,  and  the  same  out  event 
raised  by  a  process,  monitor,  package,  or  subprogram  may  ultimately  dispatch  multiple  aperi¬ 
odic  processes.  The  same  out  event  may  ultimately  both  dispatch  one  or  more  aperiodic  pro¬ 
cesses.  These  are  many-to-many  connections.  Do  we  need  to  declare  “event”  ports  that  allow 
unlimited  fan-in,  fan-out  roles? 


2.4.2.3  Event  to  Mode  Connections 

A  mode  may  be  connected  to  an  event.  When  the  event  occurs  a  change  to  the  connected  mode 
will  occur  ([MetaH  98],  Section  5.1. 6.2.3). 

Every  mode  comes  with  a  pre-declared  port,  “MH_event_port”  (declared  in  “MH_mode”). 
This  allows  event-to-mode  connections  to  be  handled  just  as  port-to-port  connections  (Section 
2.4.1). 

2.4.3  Equivalence  Connections 

Equivalence  connections  can  be  used  to  declare  that  a  pair  of  monitor  component  names,  pack¬ 
age  component  names,  or  subprogram  component  names  refer  to  the  same  object.  An  equiva¬ 
lent  connection  is  often  used  to  specify  that  a  subprogram,  package,  or  monitor  is  shared  by 
multiple  processes.  ([MetaH  98],  Section  5. 1.6.3). 

Equivalence  or  sharing  of  components  is  not  the  same  as  ACME  bindings.  MetaH  Equiva¬ 
lences  declare  that  two  component  names  refer  to  the  same  object.  ACME  bindings  declare 
that  two  ports  are  one  and  the  same.  We  could  translate  MetaH  equivalences  into  ACME  bind¬ 
ings  but  this  would  be  violating  the  semantics  of  the  ACME  construct.  The  leading  alternative 
is  to  not  map  equivalences  into  anything  and  simply  add  a  “MetaH_equivalence”  property  to 
the  members  of  an  equivalence  class  so  that  other  tools  can  tell  who  they  are.  The  down  side  is 
that  this  might  prevent  “one-pass”  translation  since  we  might  have  to  go  back  and  patch  previ¬ 
ously  processed  components  with  the  new  property  before  generating  the  ACME  code. 


2.4.4  Path  Declarations 

Paths  define  sequencing  behaviors  of  objects  ([MetaH  98],  Section  5.1.7). 

2.4.4.1  Execution  Paths 

Execution  paths  may  be  defined  inside  process,  monitor,  package,  and  subprogram  implemen¬ 
tation  specifications.  These  are  used  to  describe  possible  execution  control  paths  through  the 
components  of  an  implementation.  Execution  paths  are  typically  used  in  declarations  of  com¬ 
pute  time  attributes  for  processes  and  their  components,  and  in  the  computation  of  stack  and 
heap  sizes  for  a  process  ([MetaH  98],  Section  5. 1.7.1). 
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Execution  paths  are  captured  as  the  value  of  ACME  property  “MH_execution_path.”  The 
value  of  this  property  is  a  sequence  of  component  names. 


2.4.4.2  Error  Paths 

Error  paths  may  only  be  defined  inside  error  model  implementation  specifications.  These  are 
used  to  describe  how  the  error  states  of  an  object  may  change  in  response  to  fault  events.  An 
error  path  takes  the  form  of  a  list  of  error  state  transitions,  where  each  transition  identifies  a 
state,  an  event,  and  another  state.  The  meaning  is  that  if  an  object  is  in  the  first  state,  then  when 
the  named  fault  event  occurs  the  object  will  transition  into  the  second  state  ([MetaH  98],  Sec¬ 
tion  5. 1.7.2). 

Error  paths  are  captured  as  the  value  of  ACME  property  “MH_error_path”  defined  in 
MetaH_Family.  The  value  of  this  property  is  a  nested  sequence  of  sequences.  The  inner 
sequences  consist  of  the  three  names  (state/event/state)  in  the  error  state  transitions. 

2.4.5  Attribute  Assignments 

The  attributes  part  of  an  implementation  specification  contains  a  sequence  of  attribute  assign¬ 
ments.  Each  attribute  assignment  specifies  a  value  for  some  attribute  of  a  particular  object 
used  in  an  implementation  ([MetaH  98],  Section  5.1.8). 

MetaH  attributes  are  translated  into  ACME  properties.  Each  attribute  name  would  be  tagged 
with  “MH_”  to  avoid  conflicts  with  predefined  names  in  ACME. 

This  is  the  most  straightforward  translation;  alternatively,  instead  of  mapping  each  attribute  to 
a  different  ACME  property,  all  MetaH  attributes  could  be  captured  as  the  value  of  a  generic 
ACME  property  “MH_attribute”  with  a  value  of  the  form  <name,  value>  where  the  name  is 
the  MetaH  attribute  name. 
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3  A  Complete  MetaH  Example 


--  Code  generated  by  the  ArchEd  code  generator. 

--  Configuration:  default 

--  Date:  23  September  1994 

--  Time:  3:13:33  pm 

type  package  PORT_TYPES  is 
ANOTHER_TYPE :  type ; 

ANY_TYPE:  type; 
end  PORT_TYPES; 

type  package  implementation  PORT_TYPES . I80960MC  is 
attributes 

ANY_TYPE' SourceDataSize  :=  16  B; 

ANY_TYPE ’ SourceFile  : =  "port_types .a" ; 
ANOTHER_TYPE*SourceDataSize  :=  32  B; 
ANOTHER_TYPE ' SourceFile  : =  "port_types . a" ; 
end  PORT_TYPES .I80960MC; 
with  type  package  PORT_TYPES; 
macro  M  is 

m_out :  out  port  PORT_TYPES . ANY_TYPE ; 
m_in :  in  port  PORT_TYPES . ANY_TYPE ; 
end  M; 

with  type  package  PORT__TYPES; 
process  PI  is 

pl_input:  in  port  PORT_TYPES  .  A3SIY_TYPE; 
update:  out  port  PORT_TYPES . ANOTHER_TYPE ; 
feedback:  in  port  PORT_TYPES . ANOTHER_TYPE; 
end  PI; 

process  implementation  Pi. EXAMPLE  is 
attributes 

self 'Period  :=  25  ms; 

self ' SourceFile  :=  "pl^ports . a" ,  "pl.a"; 

self ' SourceTime  :=  2  ms; 
end  PI. EXAMPLE; 
with  type  package  PORT_TYPES; 
process  P2  is 

p2_result:  out  port  PORT_TYPES . ANY_TYPE; 
update:  out  port  PORT_TYPES . ANOTHER_TYPE ; 
feedback:  in  port  PORT_TYPES . ANOTHER_TYPE ; 
end  P2; 

process  implementation  P2. EXAMPLE  is 
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attributes 

self 'Period  :=  50  ms; 

self ■ SourceFile  :=  "p2_ports . a" ,  "p2.a"; 
self ' SourceTime  :=  5  ms; 
end  P2. EXAMPLE; 

macro  implementation  M. EXAMPLE  is 

P2:  periodic  process  P2. EXAMPLE; 

PI:  periodic  process  PI. EXAMPLE; 
connections 

P2 . feedback  <-  PI. update; 

PI . feedback  <-  P2. update; 
m_out  <-  P2 .p2_result; 

Pl.pl_input  <-  m_in; 
end  M. EXAMPLE; 
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4  The  MetaH  Example  Translated  Into 
ACME 


Family  MetaH_Family  ()  = 

{/*  BEGIN  STANDARD  METAH  DECLARATIONS  */ 

.  (see  Figure  2-1) 

/*  BEGIN  EXAMPLE  SPECIFIC  DECLARATIONS  */ 


type  package  any_type 
extends  MH_port_type 
with 

{property  MH__Interface_name  =  "port_types"  ; 
property  MH_Implementation_name  =  "I80960MC"; 
property  MH_SourceDataSize  =  16; 
property  MH_SourceFile  =  "port_types . a" ; } ; 


type  package  another__type 
extends  MH_port_type 
with 

(property  MH_Interface_name  =  "port_types" ; 
property  MH_Implementation_name  =  "I80960MC"; 
property  MH_SourceDataSize  =  32; 
property  MH_SourceFile  =  "port_types .a" ; } ; 


component  type  M 
extends  MH_macro 
with 

(port  m_out  :  MH_port 

=  (property  MH_port_type  =  "any_type"; 
property  MH__port_subclass  =  MH_out;}; 
port  m__in  :  MH_port 

=  (property  MH_port_type  =  "any_type"; 
property  MH_port_subclass  =  MH_in;}; 

}; 


component  type  pi 

extends  MH_process 
with 

(port  pl_input  :  MH_port 

=  (property  MH__port_type  =  "any_type"; 
property  MH_jport_subclass  =  MH_in;}; 
port  update  :  MH_port 
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=  {property  MH_port_type  =  "another_type" ; 
property  MH_port_subclass  =  MH_out;}; 
port  feedback  :  MH_port 

=  (property  MH_port_type  =  "another_type" ; 
property  MH_port_subclass  = 

}; 


component  type  pl_example 
extends  pi 
with 

(property  MH_Period  =  25; 

property  MH_SourceFiles  =  <"pl_ports .a" ,  "pl.a">; 
property  MH_SourceTime  =  2 ; } ; 

component  type  p2 

extends  MH_process 
with 

(port  p2_result  :  ]yiH_port 

=  (property  MH_port_type  =  "any_type"; 
property  MH_port_subclass  =  MH_out;}; 
port  update  :  MH_port 

=  (property  MH__port_type  =  "another_type"  ; 
property  MH_port_subclass  =  MH_out;}; 
port  feedback  :  MH_port 

=  (property  MH_port_type  =  "another_type" ; 
property  MH_port_subclass  =  MH_in;}; 

}; 

component  type  p2_example 
extends  p2 
with 

(property  MH_Period  =  50; 

property  MH_SourceFiles  =  <"p2jports . a" ,  "p2.a">; 
property  MH_SourceTime  =  5 ; } ; 

Component  type  M_example 
extends  M 
with 

(Representation 

(system  MH_little_system  = 

(component  p2  = 
new  p2_example 
extended  with 

(property  MH_process_subclass  =  MH_periodic ; } ; 
component  pi  = 
new  pl_example 
extended  with 

(property  MH_process_subclass  =  MH__periodic ;  }  ; 
Connector  MH_connector_l  = 
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new  MH_connector 
extended  with  {}; 

Attachinents 

{p2  .  feedback  to  MH__connector_l  .MH_sink; 
pi. update  to  MH__connector__l  .MH_source;  }  ; 
Connector  MH_connector_2  = 
new  MH_connector 
extended  with  { } ; 

Attachments 

{pi. feedback  to  MH_connector_2 .MH_sink; 
p2. update  to  MH_connector__2  .MH_source; }  ; 
};  /*  System  */ 

Bindings  = 

{m_out  to  p2 .p2_result ; 
pi ,pl_input  to  m_in; } ; 

};  /*  Representation  */ 

};  /*  Type  M_Example  */ 

};  /*  family  */ 

system  MH_system  :  MetaH_Family  = 

(component  MH_component  =  new  M^example;}; 
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5  Generating  Rapide 

Behavioral  Specif  'ations  from 
MetaH  Descriptions 


MetaH  does  not  include  a  behavioral  specification  language  as  such.  A  MetaH  description 
implies  behavior  from  the  specification  of  component  timing,  sequence  of  operations  (execu¬ 
tion  paths),  and  state  transitions  (error  paths).  If  we  want  to  take  advantage  of  available  ADLs 
simulation  or  verification  capabilities,  one  of  the  premises  of  this  work  and  a  motivation  for 
ACME,  we  have  essentially  three  alternatives; 

1 .  Do  nothing  and  translate  the  MetaH  limited  behavioral  specification  into  fragments  of 
Rapide  specifications.  This  is  not  very  satisfactory  because  the  behavioral  information  can 
be  missing  or  incomplete.  A  better  alternative  might  be  to  assign  the  generation  of  Rapide 
specifications  to  the  MetaH  timing  tool.  It  performs  schedulability  analysis  and  has  a  bet¬ 
ter  understanding  of  the  behavior  of  the  system. 

2.  Invent  a  MetaH  behavioral  specification  language  and  annotate  the  relevant  components 
with  a  new  attribute,  “behavior,”  whose  value  is  a  string  in  the  new  language.  This 
requires  writing  a  translator  from  this  language  to  Rapide. 

3.  Adopt  the  behavioral  specification  language  from  an  existing  ADL  and  annotate  MetaH 
components  with  the  attribute  “behavior”  written  as  a  string  in  that  language.  The  obvious 
candidate  ADL  to  borrow  from  is  Rapide  because  it  obviates  writing  a  translator.  How¬ 
ever,  if  there  is  already  a  translator  to  Rapide  from  a  different  ADL  (e.g.,  Wright)  we 
could  use  it  instead. 

This  aspect  of  the  translation  from  MetaH  to  ACME  (and  then  to  Rapide)  is  still  incomplete 
and  other  alternatives  might  be  considered  as  the  effort  progresses. 
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